增加新的柜员后会发生什么?
看到一篇有趣的短文《增加新的柜员后会发生什么?》,讲的是排队论。
银行柜员问题
文章中讨论了这样的一个问题:
假设一家小银行只有一名柜员,每位顾客平均需要 10 分钟的服务时间,每小时预计有 5.8 位顾客到达,那么预计每位顾客的等待时间是多少?
乍一看之下,每小时有 60 分钟,但只有 5.8 位顾客到达,即平均每 10.3 分钟才有一位新顾客到达,同时每位顾客平均只需要 10 分钟的服务时间,似乎一位柜员就足够服务好这些顾客了,每位顾客都不用等待或者不会等待太久?
但事情显然不会这么简单,假设顾客到达的时间和所需的服务时长都是随机的,那么每位顾客在得到柜员服务之前,平均需要等待近 5 小时之久!
为什么会这样?其实稍加思考,我们就能发现端倪,因为那个 10 分钟只是平均时间,但每位顾客所需的实际时间差异可能会很大,有人可能只需要一两分钟,有人则可能会需要几十分钟甚至几小时,而一旦遇到一位需要长时间服务的顾客,所有后来的顾客都只能排队等待。同时,顾客的到达时间间隔也不是严格的 10.3 分钟,有时可能几十分钟甚至几个小时都没人来,有时则一下子连着来了好几位顾客。
那么,如果增加一位柜员会怎么样呢?
你或许会以为,增加了一位柜员后服务处理能力加倍,那么顾客的平均等待时间也应该对应地减半,平均每位顾客大概只需要等待两个多小时吧?但事实上,增加一位柜员后,顾客的平均等待时间会一下子下降到 3 分钟,仅为原来的 \(\frac{1}{93}\)。
也就是说,只有一位柜员时,顾客的平均等待时间可能会长得难以接受,但增加一位新的柜员之后,顾客的体验就相当良好了。
原因也很简单,当有两个柜台同时提供服务时,如果一个柜台被阻塞了,顾客可以转向另一个柜台,而不用在后面干等。当然,也存在连着来了两位需要长时间服务的顾客的情况,这时两个柜台都被阻塞,新顾客仍然需要长时间等待,但在上面讨论的这个场景中,这种情况发生的概率很低,对等待时间的平均值影响非常微小。
泊松分布和指数分布
在统计学上,顾客的到达时间一般认为符合泊松分布,顾客所需的服务时长一般认为符合指数分布,两者都是非常常见的分布。
泊松分布通常用于描述在固定时间或空间内随机发生的离散事件的次数。比如上面例子中,不断有顾客进入银行,具体什么时候有顾客进入是一个随机事件,无法预测,但我们可以估算“指定的一段时长(比如 1 小时)内有 \(n\) 位顾客到达”的概率 \(P\) 是多少,公式如下:
\[P(X=n)=\frac{e^{-\lambda}\lambda^{n}}{n!}\]
其中 \(\lambda\) 表示事件发生的频率,这个频率是通过统计之前收集的数据得到的,比如本例中我们已知每小时预计有 5.8 位顾客到达,那么以 1 小时为单位,\(\lambda\) 即是 5.8。
根据这个公式,可以计算出 1 小时内有 n 位顾客到达的概率,当然,n 在 5.8 左右时概率最大,越偏离 5.8 概率越小。比如 1 小时内有 100 位顾客也是有可能的,只是这个概率会小得可忽略不计。
以下是一些常见的泊松分布的事件:
- 电话呼入:在一个呼叫中心,每小时接到的电话数量。
- 公交车到站:在固定的时间内到达某个公交站的公交车数量。
- 流量统计:在网站或网络节点上,每分钟的访问或数据包数量。
- 自然现象:如一定时间内某地区的雷击次数或降雨事件。
- 排队系统:例如银行柜台在特定时间内接待的顾客数量。
指数分布和泊松分布可以认为是描述相同现象的不同部分:泊松分布关注一段时间内发生 n 个随机事件的概率,而指数分布关注每两个连续的随机事件之间的时间间隔。
指数分布的公式也与泊松分布的公式相关。比如,如果想计算一段时间内某件事不发生的概率,就相当于计算上面泊松分布中 \(n=0\) 的概率:
\[ \begin{align*} P(X=0)&=\frac{e^{-\lambda}\lambda^{0}}{0!} \\ &=e^{-\lambda} \end{align*} \]
而在一段时间内事件发生的概率,则是 1 减去上面的值,即:
\[1-e^{-\lambda}\]
以下是一些常见的指数分布的事件:
- 顾客服务时间:在银行或超市收银台,每位顾客的服务时间。
- 机械故障:如电梯或生产线设备之间的故障时间间隔。
- 半衰期:放射性物质的原子衰变时间间隔。
- 交通事故:在特定路段上,两次交通事故之间的时间间隔。
- 生物学事件:如某种细胞分裂或动物捕食行为之间的时间间隔。
项目管理中的排队论
排队论在各种服务性质的工作中非常有用,除此之外,软件开发中也有很多场景可以参考。
软件的开发和维护过程与柜台服务类似,不断地有新的需求(顾客)过来,程序员(柜员)则负责处理这些需求。新需求的到达时间以及工作量都是随机的,可以大致认为分别符合泊松分布和指数分布。
团队的管理者常常会期待这样一种理想状况:每一个需求过来时都能很快得到处理,同时员工人员基本没有冗余(即没有人闲着)。但只要在软件开发团队待过就会知道,这种理想状况极少发生,大多数时候都是需求不断积压,程序员加班加点仍然难以赶上进度。
如果你仔细地测算每一个需求的工作量,以及平均每周有多少新需求,你可能会发现如果只看平均值数据,团队应该能够处理这些工作才对,但事实却是很多需求都延期了。看了上面的讨论,你现在应该知道了,很多时候工作安排并不能简单地算平均值,因为需求具有随机性,如果你希望对抗这种随机性,让新需求能尽快得到处理,一些冗余将是必须的。
当然,软件开发和柜台服务之间也有很大的不同,其中之一是开发人员通常不能简单地互换,和柜员相比,开发人员之间交接工作的成本可能会比较高。不过总体来说,排队论的思想和方法仍然是适用的。
评论:
上学的时候这些概率分布都学过,但是却没怎么和实际联系起来过……